QAuDHD #1b - What Are The Chances?
The Neurospicy Bit
Last time out I explained a bit about who I am, but that didn't leave much space to actually drop any pearls of wisdom (which is why I've started the series with this double-header). So in this article, I want to talk about something that has come up a few times recently in my discussions with other games quality folk, and which interestingly ties back to my point about the difficulty of being clear and succinct when you have AuDHD (which, in case you hadn’t picked up on it yet, is the generally accepted acronym for people like me with both autism and ADHD), especially when talking about a “special interest”.
Now for those of you who don’t know, a special interest (at least in my experience) is something which has become something of an obsession. It is something that we are incredibly passionate about, knowledgeable about and generally able to talk your ear off about whether you like it or not. For instance, I once spent a four hour walk talking to an ex about a hypothetical project I was considering starting (FOUR HOURS… whoops). According to my smartwatch, I also burned around 100cal just talking about gaming for 45mins. Who needs the gym!? (Exercise is very important for your physical and mental health, stay in school etc.).
You might, at this point, be thinking “where is he going with this?” - well that’s precisely my point. I almost went back and deleted that last paragraph because it was a tangent-filled ramble full of parentheses (I recently learned that’s an ADHD thing - it represents some of the background thoughts spinning around our heads as we communicate), but I’ve left it in because it proves my point about how hard it can be to stay clear and concise when we’re talking about something we hold so dear to our hearts. We have a million thoughts about a billion tiny facets of it and we just want you to know all of them!
Which, by the way, is why sometimes you can’t get a peep out of us and sometimes you can’t shut us up - you might think we’re being inconsistent, but especially as a manager if you can pick up on which bits we are clearly passionate about and which bits we can find mentally (and even physically) painful to talk about/work on, you’ll be able to get the absolute best out of us!
OK, so. Back onto the topic, in 500 words, and…go!
The Actual Topic
Bugs. It's all about the bugs, right? Well, hopefully I'll convince you that's not necessarily true as this series goes on, but for now let's go with it.
I'm not going to waste your time explaining the importance of bugs, or retread old ground by writing about the importance of setting an accurate Severity. Instead I'm going to discuss a less commonly used field that I always add to my bug reports: Likelihood (or Probability).
While Severity categorises bugs by “how bad it is” (from crashes to minor grammatical errors), Likelihood is about “the chances of an end-user finding it”.
Like Severity, Likelihood is sometimes a qualitative field, but you can set some hard-and-fast rules which will help keep your teams aligned. I recommend the following:
- Mainline - every person who plays your game will see this (assuming they progress far enough along the golden path)
- Likely - most users will come across this, as it exists in some sub-menu or optional feature
- Possible - some users might come across this, as it is a not uncommon for them to perform these actions (e.g. loading a save without the necessary DLC installed)
- Unlikely/Destructive - only users performing truly uncommon actions will come across this (e.g. changing WiFi networks mid-session)
So why does Likelihood matter? Well for one thing, it helps when prioritising fixes - a crash might seem like an obvious top-priority issue, but if it only happens when following a very specific, and unlikely, sequence of steps, in a lesser visited area of the game, which will be revisited later anyway, then it can slip down the priority list without much risk.
Beyond that, though, this field can also help testers to serve their main (but often misunderstood) purpose on any project - risk reduction. And I don't just mean reducing the “risk” of an end-user finding issues on the product; I mean identifying areas of risk within the development process and helping to mitigate against them.
Let's say you've got a high percentage of “Likelihood: Mainline” bugs on your project. Regardless of their severity: what does that suggest? Well, I'd be looking at communication between departments. This could be the wider team not understanding the design, or could indicate a flaw in the design itself (e.g. not accounting for all the ways a player might approach a mission). It could be a problem in the process of going from greybox to art-ed levels, resulting in gaps in the collision (e.g. not making it clear what areas are playable and what is backdrop) or unclear goals.
Regardless, it's reasonable for unusual use cases to cause issues, but bugs being reported as “100% of players will see this” speaks to a deeper problem somewhere. Couple this with good feature-based labelling for your bugs, and you can easily spot problem areas in your project (although remember that some features, by their nature, may never be considered “Mainline”, so remember to adjust your bar for “this area is a problem” accordingly).
500 - done!
